This blog was co-written by Brook Schoenfield and Damian Quiroga.
I am a wry observer of vulnerability announcements. CVE-2017-3735—which can allow a small buffer overread in an X.509 certificate—presents an excellent example of the limitations of the Common Vulnerability Scoring System (CVSS). This scoring system is the de facto security industry standard for calculating and exchanging information about the severity of vulnerabilities. The problem is that CVSS is used for far more than it was intended.
For many organizations, security tools, and risk assessments, a CVSS score has become the security industry’s shorthand substitute for risk scoring and impact rating. In fact, many organizations measure their ongoing risk posture by counting the number of unfixed vulnerabilities and their associated CVSS scores.
The McAfee Product Security Incident Response Team (PSIRT) uses CVSS Version 3.0 as an important tool to assess vulnerabilities. McAfee PSIRT augments CVSS with other risk analysis techniques, similar to Microsoft PSIRT’s Exploitability Index and Security Update Severity Rating System.
CVSS is useful, but must not be confused with deeper risk assessment. Strictly relying on CVSS for vulnerabilities such as OpenSSL’s CVE-2017-3735 is likely to cause incident responders to focus their organizations’ resources on patch cycles that may be unnecessary. In addition, PSIRT credibility and influence may be squandered on low-impact, low-probability issues. Due to the sheer volume of issues being discovered and reported, PSIRT must remain focused on those that have a high probability of exploitation and whose organizational impact or attacker value make them worthy of exploitation.
But as we shall see from the following analysis, a vulnerability itself, taken out of context, cannot be equated to risk. Furthermore, CVSS has an inherent problem in that the impact is averaged against the exploitability: From the attacker’s perspective, this is a mistake, because threat actors exploit vulnerabilities to suit their goals, not just because something is easy.
For those readers whose sole interest is assessing OpenSSL CVE-2017-3735, this issue, I believe, should be rated as a low to very low risk. Although easy to perform, exploitation does not offer an attacker much of value. The most likely impact will be cosmetic within a text display. Plus, the code in which CVE-2017-3735 occurs is not called from OpenSSL’s protocol and cryptographic functions,[1] but is rather confined to the display of an X.509 certificate, typically for users consumption. (Certificate display does not take place as a part of typical cryptographic functions.)
Taking either of the competing published CVSS scores for this vulnerability, 5 or 7.5, at face value is misleading. Without further analysis, one might be tempted to raise the risk from CVE-2017-3735 beyond its rather minor impact. That is why I decided to investigate further, including reading the offending module’s code on GitHub. The CVSS measure of CVE-2017-3735 provides a situation where accurate scoring does not match the likelihood of exploitation and increases the score above what a risk analysis would probably reach.
Although it is true that attackers must choose exploits that lie within their technological capabilities—namely, exploits that are easy enough to ensure success—the first concern will nearly always be, “What will the exercise of this vulnerability achieve for me?”
In other words, what matters is the impact or result from the exploitation that is key to choosing a particular attack, not its relative ease or difficulty. If a vulnerability advances the attacker’s goals, then it will be considered for use. If there is nothing to gain, the vulnerability will not be exploited.
Limits to CVSS
Attackers exploit vulnerabilities that further their goals: That is a key point when assessing the potential for harm of any vulnerability. In this analysis, we will take a closer look at CVE-2017-3735 for its potential value to attackers. Along the way, we will also examine some of the limitations of CVSS as it applies to this vulnerability.
I do not mean to assert that CVSS is not an important tool for assessing vulnerabilities. I have worked with CVSS since before Version 1 was published; CVSS is key to prioritizing initial responses to vulnerabilities as they are released. CVSS may comprise one component of a robust risk rating method or approach.
I like to characterize CVSS as “potential severity.” A CVSS score, when fairly calculated,[2] can indicate what any vulnerability might harm. CVSS scores are particularly useful for triage, before a deeper analysis.
The McAfee PSIRT makes use of CVSS as a core component of incident response, just as many organizations PSIRTs do. As a CVE Numbering Authority, McAfee PSIRT must calculate a CVSS score for every published vulnerability. In practice, nearly every potential issue is scored as a critical foundation of PSIRT’s robust risk assessment.
Still, despite the importance of CVSS to vulnerability triage, it is a mistake to confuse a CVSS score with a risk rating, as we shall see.
CVE-2017-3735 has had two competing CVSS scores published.[3] The difference is in the rating of the impact: Integrity = High or Integrity = Low, resulting in a combined score of either 7.5 or 5.3 (in CVSS Version 3.0). In either case, both scores earn the exploitability rating of 10, because the issue may be exploited over a network without authentication.
CVSS = 7.5 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
(From: https://nvd.nist.gov/vuln/detail/CVE-2017-3735)
CVSS = 5.3 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
(From: https://nvd.nist.gov/vuln/detail/CVE-2017-3735)
How can there be two CVSS calculations? Why is one calculation High and one Low? Plus, is Integrity the correct impact parameter?
We can answer these questions by analyzing what the vulnerability allows.
The vulnerability is a buffer overread. An attacker may read one more byte from program memory than should be allowed. The attacker’s advantage of the unallowed access is directly related to where that extra byte exists. After looking at the code on GitHub, it appears all buffers in that module are allocated from program heap memory. Although running programs can exhibit macro patterns in their heap allocations and deallocations, generally, we can assume that any allocation may reside wherever it is convenient for the program memory manager to grab a piece of memory sufficiently large to support the request. This introduces an element of entropy (randomness) into any particular allocation. Each allocation may come from any portion of heap memory; there is no guarantee of a particular address.
Because a particular address cannot be guaranteed, an overread will get whatever bytes happen to be larger than that allocation’s required size.
Whichever data happen to be at that address is what the overread vulnerability will retrieve. Buffer overread exploitation can be a fishing expedition; there are no guarantees of the data retrieved, though there may be macro patterns in programs in which runtime processing is relatively consistent from run to run. The data returned depends on how lucky the attacker is. We saw the same situation in the Heartbleed overread vulnerability.
Just One Byte
For CVE-2017-3735, the overread is precisely a single byte. That is a very small payoff for the attacker, especially considering that there is no guarantee of what that byte might contain.
Furthermore, even if this were not an overread but rather an overflow (which it is not), a single byte is not enough space for malicious code to allow an attacker to exit to a command shell. A buffer overread does not allow an attacker to push code into a program heap. It allows an attacker only to retrieve data (a single byte) that the attacker should not have reached.
Although we may be surprised some day by a clever attacker’s ingenious use of a single byte, today we see no way that anyone can benefit.
If CVE-2017-3735 allows an attacker to retrieve only a single byte, then why have CVSS scorers used the Integrity impact rather than Confidentiality? Heartbleed, a heap buffer overread that returned nearly 64KB to the attacker, impacted Confidentiality. Attackers retrieved data they should not have been able to access. Yet CVE-2017-3735 has been scored on Integrity. There is a clue alongside the description.
Because I do not have access to the graph of code calls to the vulnerable IPAddressFamily routines, I cannot confirm the following educated guess. However, typical cryptographic and protocol implementations do not dump certificates to text; primarily users do. Which indicates that an attacker does not retrieve the extra byte. Instead, the extra byte is converted to text in the IPAddressFamily certificate extension’s human-readable dump. Thus the integrity of the text representation of an X.509 certificate has been impacted. With this understanding of the impact, scorers have used Integrity rather than Confidentiality.
If the attacker retrieves the text dump, is there a way to track back from various text irregularities to the value of the extra byte? I have not looked at a range of dumps to confirm or deny. Perhaps this is either not possible or not a productive approach.
If there is any way to retrieve the data byte, then the proper CVSS score would have to be Confidentiality = Low rather than None, which would increase the CVSS score to either 6.5 or 8.2, depending upon Integrity’s value, Low or High.
A CVSS score of even 5.3 gives a luster of importance to CVE-2017-3735 that it does not deserve. Any of the potentially higher scores suggest the wrong direction, which is probably why scorers refrained from including the potential for a confidentiality impact. Still, we should analyze this score to understand the strengths and limitations of CVSS. If scored for all impacts and the ease of exploitation at 6.5, CVSS indicates that this is an important vulnerability that should be addressed in a timely manner. Yet if my analysis is correct, CVE-2017-3735 should not move to the top or even middle of anyone’s work queue. Patch it in due time, through scheduled update cycles. Nothing more.
The potential impact from CVE-2017-3735 is probably not significant in the vast majority of OpenSSL’s use cases. Integrity = Low, maybe Confidentiality = Low, too. Attacker utility = None.
In fact, the most often published description for CVE=2017-3735 indicates the trivial nature of any impact: “The most likely result would be an erroneous display of the certificate in text format.” (See References.[4])
After reading this analysis, I hope it is clear that CVSS fails to account for the complete situation with respect to CVE-2017-3735.
Unequal Weights
As we mentioned, the exploitability and impact scores are each weighted equally (actually, averaged). From the attacker’s view, this is inaccurate.
Attackers do not equally exploit every vulnerability. More important, attackers do not choose to exploit a vulnerability simply because it is easy to exploit. They have no time for that; attackers are trying to achieve their goals, whatever those may be. Anyone prioritizing vulnerability responses needs to keep this in mind as we analyze.
The following published description for CVE-2017-3735 is, at the very least, misleading and erroneous, considering the single-byte heap buffer overread affects only a user-initiated text dump:
“Successfully exploiting this issue will allow attackers to bypass security restrictions and perform unauthorized actions; this may aid in launching further attacks.”
There are no “security restrictions” involved in a certificate transformed to text. Further, a single byte is insufficient to enable “launching further attacks” even if the issue were more than an overread: The attacker cannot gain control of program memory through this flaw.
Quite often, organizations have hundreds or thousands of vulnerabilities to examine. To which should they respond first? Which response should get the most resources? Which of the perhaps dozens of vulnerabilities announced in any week or month can be allowed to remain open in the face of limited resources?
These are fundamental questions that every organization must answer, probably every day. One way to prioritize is to begin assessing the potential impact to the organization and the potential utility to the attacker. These two dimensions are more important than how easy or difficult a vulnerability is to exploit, although that also important information once we determine that a vulnerability is significant.
Calculating CVSS helps practitioners identify those items that warrant deeper analysis. Unfortunately, due to the way that a CVSS base score is averaged across the exploitability and the impact dimensions, CVSS in some instances fails to sufficiently assess risk, especially in cases where utility to an attacker appears to be relatively insignificant.
The McAfee PSIRT uses CVSS as a critical tool for triaging vulnerabilities and for gauging response times. Still, CVSS is no substitute for a deeper risk analysis when it is warranted.
Notes
[1] We did not have access for this analysis to an OpenSSL code graph, which would have allowed a definitive examination of calls to the vulnerable code. However, it appears from a cursory examination that the module is primarily called upon user instigation, from command-line tools, not during protocol processing.
[2] There are numerous cases of scores being inflated or deflated to fit the agenda of the scorer. How can cross-site scripting scores range from 1.8 to 9? That seems impossible, but a simple search will return that range of scores from Mitre’s CVE data.
[3] Vendors may calculate alternate scores for their products, which will be dependent upon particular vendor circumstances.
[4] One published description seems to vary considerably. The following does not seem to match our reading of the code or the behavior of a single-byte heap buffer overread:
“Successfully exploiting this issue will allow attackers to bypass security restrictions and perform unauthorized actions; this may aid in launching further attacks.”
Stay Updated
Follow us to stay updated on all things McAfee and on top of the latest consumer and mobile security threats.
